Using B to Design and Verify

Machine Notation (AMN) [1], this means that safety requirements expressed as module invariants can be shown to be preserved by each low-level controller action (under the assumption that higher level controllers invoke low-level controller actions within their preconditions), and that these invariants are preserved in the re nement process towards an executable implementation. The combination of formal methods and controller synthesis gives the following advantages: { A systematic way of obtaining the controller speci cation and design is provided by the synthesis process; { The formal method provides a means of de ning and verifying highlevel controller states representing goals (eg: lling or levelling in the case of the tank example [20]) which are more suitable for an operator to deal with than the atomic level states used in the procedural controller; { The formal notation and its tool support provides veri cation of the controller after its design, and validation of the requirements before controller synthesis. The modularity mechanisms of B in particular support a decomposition of veri cation into a number of steps: showing that the low-level controller operations maintain the safety invariants (that undesired states are avoided), provided they are called within their preconditions, and that higher-level controllers invoke these low-level operations within their preconditions. In the rest of this section we introduce the concepts of procedural control and give an overview of the proposed method combining controller synthesis and formal speci cation and veri cation. Section 2 describes the steps of the method for the gas burner case study. Section 3 compares the B approach with other speci cation approaches for reactive systems. Section 4 summarises our proposed enhancements of B. 1.1 Procedural Control A procedural controller is a nite state machine in which each state either has: (i) a unique transition leaving it which is controllable (i.e., which corresponds to an output from the controller to the controlled system); or (ii) only uncontrollable transitions leaving it. Uncontrollable transitions are triggered by inputs from the controlled system to the controller. States in case (ii) are termed \wait states" { they are states where the controller is waiting for some input event before proceeding. The standard process for the synthesis of procedural controllers is [24, 25]: 1. Input Information: { Input-output models for elementary components (i.e. nite state machine (FSM) or statechart models for valves, timers switches, etc) in which transitions are classi ed as process responses (uncontrollable transitions) or control commands (controllable transitions) { Static Speci cations. Speci cations describing forbidden states (i.e. states that must be avoided during operation). These states are modelled as logic statements. In particular, hazard states would normally be speci ed as forbidden states. { Dynamic Speci cations. Speci cations describing dynamic behaviour to be imposed upon the process. These include normal, abnormal and emergency operation. They can be captured as temporal logic (RAL [18]) formulas. 2. Model building using a model-checker such as SMV [5] 3. Synthesis of controller superstructure, including the controllability analysis of the resultant superstructure 4. Synthesis of a procedural controller, which de nes the ordering of sequences of controllable transitions in response to uncontrollable transitions occurring from each reachable state. 1.2 Method The following steps are taken in the synthesis and implementation of a controller for a reactive system using the combined method (Figure 1): { Identify the elementary components of the system { the sensors, controls and actuators which it involves, and give their behaviour via statecharts. Notice that this implies that all components are modelled as nite state machines: this is an abstraction away from continuous behaviour, which could be modelled via the time variables of VDM++ [9]. { Identify the controllable and uncontrollable actions of the system components. The latter will usually form the list of events to which the controller must respond, whilst the former will correspond to events generated by the controller. { Identify invariants of the system which must be maintained at all times, and which can be maintained by the inhibition of controllable actions. { Identify the marked system states { states of particular signi cance for the system, such as an initial state, or a state of desired activity. { Identify the procedural speci cations { these de ne the expected order of occurrence of actions. Using this information, the synthesis of a procedural controller is a toolsupported process [24], yielding a statechart which satis es the constraints given above. This statechart yields the de nition of a high-level controller as follows. The high-level controller has states which correspond to the wait states of the procedural controller, and transitions corresponding to the paths between successive wait states in the procedural controller. These transitions are triggered by the uncontrolled events at the start of these paths. We may also group controller states into higher-level modes representing goals [20]. A group of wait states connected only by uncontrolled transitions may be combined into a single high-level state (for example, consider the alarmed state in the gas burner controller). A B machine speci cation can be derived for each of the elementary components using their statechart descriptions. The aggregate of all of these modules forms the basis for an abstract speci cation of the uncontrolled system. In this module we can place logical constraints which express the assumptions which are being made about the physical properties of the system (these are properties which inevitably hold, and which do not need to be ensured by the controller). The aggregate of all those machines which correspond to actuators controlled by the controller forms a model of the output part of the controlled system. In this aggregate we can place the invariants identi ed in the analysis stage, and place restrictions (preconditions) on the operations corresponding to controllable actions which ensure the preservation of these invariants. Temporal constraints and procedural speci cations are also included in this aggregate module (in the extended language), if they refer only to controlled actions. This constrained aggregate is termed DCF Diagram spec. of unconstrained system constrained system LL_Controller Elementary Components (Statecharts) Invariants (Forbiddon States) Procedure Specifications (LTL) Events & Marked States Controller Synthesis Controller Procedural Statechart High-level Controller Statechart high-level controller Controller Design Validation via animation; Verification of internal consistency Executable System Refinement: verification of refinement steps Non-automated Process Automatable Process